Databases have become the subject of significant recent interest, not only because of the increasing volume of data being stored and retrieved by computerized databases but also by virtue of the data relationships which can be established during the storage and retrieval processes. Most of the interest in databases has concerned users' demands for an improved ergonomic interface to the database through innovative display technology.
Among database objects, table objects are the basis for data storage and retrieval. In a relational database design, data redundancy should be minimized while maintaining data integrity and performance efficiency. To increase the flexibility in retrieving and updating data in the base tables, database view objects are created to provide specific portals to the data in one or more base tables and/or other view objects. View objects also provide a means to control data accessibility by specifying users' authorization on view objects. The view objects are commonly used to hide columns in base tables, select columns from multiple tables into a logical format, and access a subset of the data from base tables.
The complexity of defining a database view object grows with the number of participating base table or view objects, the conditions specified for data selection, the columns selected into the view, the necessary aliases specified for the tables and views involved, and the relationships specified among the selected database objects. A user interface that can help the user handle this complex process for defining a database view object becomes important to database administrators and users. This interface can also be used to define complex SELECT statements that use set operators and/or nested SUBSELECTS.
From a SQL standpoint, a database view object is defined by a FULLSELECT statement, which is composed of a set of SQL SELECT statements. The simplest form of a view object is based on a single SELECT statement with a single base table involved. More likely, the definition of a view object will include multiple SELECT statements and the relationships between them will be specified by set operations (UNION, INTERSECT, etc.). When set operations are involved in a SQL FULLSELECT definition, it is usually difficult for the user to construct the FULLSELECT statement in a plain and flat textual format. In defining a complicated FULLSELECT statement, a user typically thinks from the view object's basic building blocks, which are SELECT statements, and the relationships among the building blocks. A pictorial construction of a FULLSELECT in most users' mental model is like using a Venn Diagram to describe a specific area as discussed in modern algebra.
Structured Query Language (SQL), and in particular ANSI SQL, has become a preferred language media for communicating queries to relational databases. As a consequence, there presently exist thousands of relational databases and thousands of related queries directed to such databases. Given an investment in such databases and queries, migration is not only a desirable feature, but a substantially necessary capability for new relational database systems and methods.
The concept of portraying a query in a graphical depiction on a display screen of a workstation is a relatively new approach to relational database interfacing. Visual queries, often referred to as graphical queries, utilize workstation graphics to represent query objectives heretofore defined by SQL statements. A visual query presents a pictorial depiction of the objectives of a search, thereby eliminating any need for a user to learn a query language, improving the rate at which SQL queries can be formulated, and reducing the defect or error rate of queries.
An example of a prior art approach to a database user interface is found in IBM Technical Disclosure Bulletin, vol. 33, no. 9, pp. 243-6, February 1991, entitled Interactive Schema Diagram to Visually Represent Tables of Related Data and Meaningful Joins Between Tables. The article discusses a non-procedural, graphical relational database interface. The interface uses the database schema graph as a top-level directory and access tool for manipulating tables, attributes and relational join operations.
Another example of a user interface for interfacing to a database application is U.S. Pat. 4,853,843 entitled, System For Merging Virtual Partitions of a Distributed Database. This patent discloses an object-oriented distributed database application which is divided up into partitions. Each partition merges the databases into a single merged database which permits versions of data objects and collections of data objects to be identified and accessed in the merged database.